Abnormal Dxl Execution

Hello everyone,

 

I'm contacting you to share and maybe find a solution to my strange problem.

I'm developing simple scripts to know about links between modules, and right in a file under the temporary folder. The script has been done since multiple weeks, and it works well.

But it appears that sometimes,  the script will crash in any case even when I'm 200% it should. At the beginning I though it was my script... I was looking for something like a mistake... but 10 min later it started to work again...

Now I know that when it fails, I have to wait ~10min before I can run it again... Also, sometimes after restarting Doors it works...

 

I'm really confused. Does anyone already encountered such problem ?


Joooris - Tue Mar 07 10:00:00 EST 2017

Re: Abnormal Dxl Execution
Mathias Mamsch - Tue Mar 07 10:36:10 EST 2017

DOORS development can be a pain ... The reasons for weird behaviour can be plenty. You need to come up with some specific error messages apart from "crash" ... What exactly happens? Do you get a DXL error? Does the DOORS process terminate? Are there any messages? Also can you post relevant parts of your DXL script? If your script works for 10 minutes, then not, chances are that your script tries to edit a locked module or something like this. Regards, Mathias

Re: Abnormal Dxl Execution
Joooris - Wed Mar 08 03:46:25 EST 2017

Hi, thanks for the answer.

If your script works for 10 minutes, then not, chances are that your script tries to edit a locked module or something like this

Actually this is the opposite : it will work for a long time, and stop working for 10 minutes. When it happened, I noticed that the script execution became really slow. 

Note that the script does not edit any module. It is looking for LinkSet according to the name of the module given in 'targetFullnames[0]'.

Then the error come from this : 

targetItem = item(targetFullnames[0])
if (null targetItem)
{
    errorDisplayExit("Wrong module path provided : "targetFullnames[0]"", location)
}

Where "errorDisplayExit" is a function with halt() call after displaying the message.

 

Here "targetFullnames[0]" is the full name of a module. By conception the item could not be null because the value of "targetFullnames[0]" comes from the function "fullName(Module m)" with an existing module as argument.

Once the error is raised, I copy past the value of "targetFullnames[0]", then tried to get the item, and I had the same result. But if I enter this value in the address bar, Doors opened the module that mean it exists.

And as I said, after some minutes, the item will not be null whereas I use the same value. 

 

Thank you !!

 

Edit :  dxl script uploaded. To make it work : update line 112 (ie. "C:\\Users\\xxx\\Desktop\\file.txt") and line 113 (ie. "/ProjectTest/folder/moduleName")


Attachments

generateFileOfLinkedModule.dxl

Re: Abnormal Dxl Execution
Mathias Mamsch - Wed Mar 08 07:25:16 EST 2017

Joooris - Wed Mar 08 03:46:25 EST 2017

Hi, thanks for the answer.

If your script works for 10 minutes, then not, chances are that your script tries to edit a locked module or something like this

Actually this is the opposite : it will work for a long time, and stop working for 10 minutes. When it happened, I noticed that the script execution became really slow. 

Note that the script does not edit any module. It is looking for LinkSet according to the name of the module given in 'targetFullnames[0]'.

Then the error come from this : 

targetItem = item(targetFullnames[0])
if (null targetItem)
{
    errorDisplayExit("Wrong module path provided : "targetFullnames[0]"", location)
}

Where "errorDisplayExit" is a function with halt() call after displaying the message.

 

Here "targetFullnames[0]" is the full name of a module. By conception the item could not be null because the value of "targetFullnames[0]" comes from the function "fullName(Module m)" with an existing module as argument.

Once the error is raised, I copy past the value of "targetFullnames[0]", then tried to get the item, and I had the same result. But if I enter this value in the address bar, Doors opened the module that mean it exists.

And as I said, after some minutes, the item will not be null whereas I use the same value. 

 

Thank you !!

 

Edit :  dxl script uploaded. To make it work : update line 112 (ie. "C:\\Users\\xxx\\Desktop\\file.txt") and line 113 (ie. "/ProjectTest/folder/moduleName")

Hmmm ... I do not see something very special about your code that would be inviting troubles. Lets try to sort this:

- Script Slowdown:

     - Script slowdown usually happens due to a) Memory Leaks inside your code  and b) String Table littering. But for these you would have to run this script in a loop for a vast amount of modules to make this noticable.

     - There is one exception, that could cause slowdown:  Logging. Collecting Logs the wrong way (appending to a string) can fill up your memory in no time, but either you removed some logging code or this is not the case with your script. Did you remove any logging code?

    - I am not sure if LinkModuleDescriptors are suffering from leaks in DXL - but again, you would have to run your script from a loop inside the same DXL session to make this matter .... Did you search the forum for problems with LinkModuleDescriptors?

- Null Target Items:

   - I see really only three reasons for you to get a null target item:

        a) Somebody is really purging modules, or constantly changing the access rights of the items

        b) Some data corruption is happening inside your DOORS database or with your network connection

        c) Your client is badly broken, either by another DXL script that corrupts the internal memory or by an unclean modification

All of the above (except a) is prettly unlikely and not heard of at least by me. Maybe someone else has similar experiences. So a few questions that might get us in another direction:

- Do you run this script in a special way? (e.g. from Java) Repeatedly? Or from the Menu/DXL Interaction Window?

- What DOORS Version are you using (client/server) ?

Regards, Mathias